Skip to content

Conversation

@ScottDugas
Copy link
Collaborator

@ScottDugas ScottDugas commented Sep 3, 2025

This introduces a new KeySpacePath.exportAllData to export all the data stored in the path. This can eventually be used to import into another cluster, or back into the same cluster, after clearing.

Other than the path information, the data exported is raw bytes, with no transformation or indicated semantics.

Resolves: 3572

@ScottDugas ScottDugas added the enhancement New feature or request label Sep 3, 2025
@ScottDugas ScottDugas changed the title Keyspacepath export Add new KeySpacePath.exportAllData Sep 5, 2025
import javax.annotation.Nonnull;
import java.util.UUID;

/**
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case you're reviewing this top-to-bottom, this class was extracted from KeySpaceDirectoryTest, but setupSampleData was added.

@ScottDugas ScottDugas marked this pull request as ready for review September 8, 2025 16:56
Copy link
Collaborator Author

@ScottDugas ScottDugas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through a bunch of the comments, and responded. I've made a bunch of the changes locally, but when I got to implementing DataInKeySpacePath.equals/hashCode, I discovered that ResolvedKeySpacePath does not implement those correctly. I'm going to pause, the work on this PR, to resolve that. I'm submitting my commits in the meantime, for visibility.

I left a TODO for myself to add unit tests of withRemainder...
I updated the tests to not use KeyValue directly, at which point,
having DataInKeySpacePath expose the value and not the raw KeyValue
seemed to make sense
keySpace.root().getValue(), keySpace.root(), context));
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a test that fails to resolve a key?
Would it make sense to add test for resolve with NULL value?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a test that fails to resolve (has a different root)

Regarding NULL, are you suggesting creating a DataInKeySpacePath with KeyValue(key, null), or a path that has a NULL type in it?
For the former, I don't think FDB will ever return such a KeyValue, and if you have one, you would never be able to insert it, because set does not allow a null value. Give that, it probably makes sense to have DataInKeySpacePath error if it gets a null value.

For the later, I think that should be better tested in KeySpacePath.toResolvedPathAsync.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant the later - NULL type.

Predominately:
- DataInKeySpace now errors if it gets a null value
- Improved javadoc linking KeySpace.resolveFromKeyAsync and
  KeySpacePath.toResolvedPathAsync
- Fix error message in default method
- Reduce visibility of ResolvedKeySPacePath.withRemainder
- new negative tests in DataInKeySpacePathTest
- Better coverage of exporting with mixed-type sub-directories
@alecgrieser alecgrieser merged commit 4542468 into FoundationDB:main Oct 29, 2025
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add KeySpacePath.export method

3 participants